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[57] ABSTRACT 

An event logging system is provided for an interactive 
entertainment network system having a headend or content 
provider interconnected via a distribution network to mul- 
tiple user interface units. Each user interface unit has an 
event evaluator to determine whether an event is a loggable 
event. The user interface unit can be dynamically reconfig- 
ured to choose different groupings of events for logging. 
Loggable events are reported to an event log manager at the 
headend over the distribution network. The event logging 
system is designed so that the user interface unit does not 
need to know the exact location of the event log manager at 
the headend. The event log manager selects an appropriate 
database to store event information pertaining to the 
reported event. The database selection is based upon the 
kind of event being logged. The database might be local at 
the headend or remote therefrom. The event logging system 
is also designed to permit the operator to reconfigure where 
the events are actually logged to promote flexibility in 
resource allocation. 
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EVENT LOGGING SYSTEM AND METHOD same computer that the operating system is running. The 

FOR LOGGING EVENTS IN A NETWORK Windows NT® event logging process can also be conducted 

SYSTEM over a network, wherein events are logged on another 

computer remote from the host computer where the event 

TECHNICAL FIELD 5 arises. To accommodate remote logging, however, the host 

This invention relates to interactive entertainment net- computer must know the remote computer to-which events 

work systems. More particularly, this invention relates to are l°§S ec *- 

logging events occurring on interactive entertainment net- Conventional event logging procedures are not well suited 

work systems. for the ITV environment. Given the vast size of the ITV 

10 system, it is difficult for a logging component at the headend 

BACKGROUND OF THE INVENTION t0 track all of the distributed television units with respect to 

Cable television systems are well-known and widely used me ^ events * 

for delivering high quality video to home televisions. Sub- Accordingly, there is a need to design an event logging 

scribers of cable television services are offered a broad array system that can be used in the interactive television envi- 

of programs, including traditional broadcast programs and 15 ronment that (1) offers global, centralized logging at the 

special made-for-cable programs. Cable television services headend; (2) enables the logging facilities to be conveniently 

also offer some selective services in which a viewer can relocated within the headend without disrupting the logging 

order by telephone to watch a special program. An example process; and (3) a very large number and high frequency of 

of this type of service is Pay-Per-View®. events from the many televisions units. 

Newer, interactive television (ITV) systems expand the 20 SUMMARY OF THE INVENTION 

assortment of services that can be provided to a viewer s 

home. ITV systems have a computerized control center, This invention provides an event logging system for an 
known as the "headend", which interactively communicates interactive entertainment network system that is capable of 
with multiple distributed television units located in sub- 25 centrally logging a large number of concurrently received 
scriber homes, thereby allowing subscribers to order or events generated at subscriber homes. The interactive enter- 
select services from their own televisions. ITV systems offer tainment network system has a centralized headend inter- 
the same traditional services of familiar cable television as connected via a distribution network to multiple user inter- 
well as a variety of new additional interactive services, such face units located in subscriber homes. An example user 
as on-demand applications. Examples of on-demand appli- 3Q interface unit is a TV set operably connected to and con- 
cations include video-on-demand which permits a viewer to trolled by a set- top box. Individual events are generated and 
order videos and watch them at his/her own time schedule, detected at the user interface units. For example, channel 
home shopping applications which enables a viewer to up/down, button presses, service requests, warnings, and 
browse various stores and catalogs on TV and order products errors are possible events that might be detected at the user 
from home, and financial applications which allow a viewer 35 interface units. 

to conduct banking and other financial transactions using the Each user interface unit has a processor and a log appli- 

television, cation program interface (log API) executing on the proces- 

During operation of ITV systems, it is desirable to record sor. The log API determines whether an event is a loggable 

events reflecting operation of the system. There are several event, which should be recorded, or a non-loggable event 

reasons for logging events, including to monitor system 40 which should not be recorded. The log API looks to an event 

operation, detect system errors, and derive statistical data. filter criteria stored in a shared memory at the user interface 

This latter reason is particularly beneficial for monitoring unit to assist in deciding which events are to be recorded and 

usage patterns for resource planning and marketing infor- which are not. 

mation. For example, a system operator in charge of pro- The event logging system includes an event configuration 

viding the programming to the subscribers might be inter- 45 manager which configures the event filter criteria kept in the 

ested in certain viewer usage patterns, such as what shows shared memory at the user interface. In the implementation 

the viewer watches, how often the viewer tunes in, how described below, the event configuration manager resides at 

frequently the viewer changes channels, and so forth. Mer- the headend and writes the event filter criteria to the shared 

chants offering video catalogs over the ITV system might be memory over the distribution network. In this manner, the 

interested in viewer shopping patterns, such as how often 50 event configuration manager can effectively program a 

viewers used the home shopping application, how many selected group of user interface units by simultaneously 

viewers opened a particular merchant's catalog, what items broadcasting the event filter criteria to that selected group, 

in the catalog attracted the most attention, whether viewers The event configuration manager employs a standard 

returned to browse the same catalog multiple times, and so network/database protocol, such as SNMP (Simple Network 

on - 55 Management Protocol), to communicate with the shared 

The process of recording events is referred to as "event memory at the user interface unit, 

logging", a terminology adopted from the meticulous prac- A group of interoperable servers are resident at the 

tice that a ship's captain uses to enterdaily notes during a sea headend. The event configuration manager executes on one 

voyage. In the electronic world, events are logged in storage or more of the servers. Additionally, a logging service 

devices and later used in statistical analysis to derive some 60 executes on one or more of the servers. The logging service 

desired information concerning usage and operation of the is preferably configured as a callable object with a defined 

system. interface. The log APIs resident on the user interface units 

Some computer operating systems have an event logging call to the logging service object using remote procedure 

component. The operating system Windows NT® from calls (RPC) over the distribution network. The RPCs locate 

Microsoft Corporation logs events which reflect operation of 65 the interface for the logging service object no matter where 

the computer system. The events are logged locally to a the logging service object is physically residing at the time, 

storage, such as the hard disk drive, that is resident on the The log APIs call and bind to the logging service object to 
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report loggable events detected at the user interface units. By system is embodied as an interactive television system 

using a COM-based (Component Object Model based) having a centralized computer center or headend 22 which 

architecture, the logging service object can be moved to is configured to serve video content programs and interac- 

different servers at the headend as planning or organization tive services to multiple subscriber homes. Such programs 

needs change, without affecting the event logging operation. 5 and services might include, for example, traditional broad - 

This promotes tremendous flexibility. cast TV shows, cable programs, on-demand movies, video 

The event logging system further includes multiple data- games, home shopping services, and banking services, 

bases to store event information pertaining to different kinds A single headend 22 includes at least one server. In the 

of loggable events. In the preferred implementation, the illustrated embodiment, the headend has a set of interoper- 

databases are ODBC-compliant databases (i.e., Open Data- 10 able servers, which is represented a server system 24. One 

Base Connectivity compliant databases) such as SQL headend 22 is designed to service 250,000 or more homes. 

(Structured Query Language) servers. Some of the databases -j^ interactive entertainment network system 20 also has 

reside locally at the headend to log event information a user interface unit 16 located in each subscriber home. One 

pertaining to system operation and viewer usage patterns. example implementation of a user interface unit 26 is a 

Other databases might reside remotely from the headend to « box ( STB ) coup i e d to control a conventional televi- 

log event information pertaining to events that are not sion set (TV) or other type video display device. The set-top 

related to system operation. For instance, a merchant that box 26 receives digital video signals from headend 22 and 

sells its wares over the interactive entertainment network controls which programs or services are displayed to the 

system might possess a database to record event information user instead of separate STBs, however, the user interface 

pertaining to loggable events that reflect the viewers' behav- 20 umt caQ be mcorporated into the TV itself. In addition to 

ior in reviewing that merchant's catalog. television and STBs, the user interface unit might be imple- 

The logging service object at the headend is configured to mented with other types of viewer computing units, such as 

select an appropriate database from among the multiple a computer and monitor. 

databases to store the event information for all of the Headend 22 is interconnected to the subscribers' homes 

loggable events reported by the user interface unit. In one v j a an interactive distribution network structure, which is 

implementation, a service string store at the headend pro- represented by a network cloud 28. One exemplary imple- 

vides a relational list correlating the appropriate database for mentation of the distribution network is a hybrid fiber-optic/ 

a given kind of loggable event reported by the log API. The ca bl e distribution network that employs digital switching 

logging service object utilizes the service string store to technologies such as asynchronous transfer mode (ATM) for 

select the appropriate database for storing event information bi-directional communication between the headend and 

pertaining to that loggable event. individual subscribers. This multi-tier distribution system 

The event logging system also has a database manage- includes a high-speed, high-bandwidth fiber optic cable 
ment application executing on one or more servers to route coupled between the headend and many regional distribution 
the event information from the logging service object to the 35 nodes. The speed and bandwidth of the fiber optic cable 
appropriate database selected by the logging service object. affords the desired performance for supporting a frilly inter- 
This database management application is preferably a thin active system. Each distribution node is then connected to 
ODBC application program interface layer used to locate multiple set-top boxes within the region via conventional 
and communicate with the appropriate ODBC-compliant home entry lines, such as twisted-pair telephone lines or 
database selected by the logging service object. This aspect 4Q coaxial cable. As an example, each regional distribution 
also promotes design flexibility in that the locations for node might support approximately 1200 homes. Although a 
storing event information can be dynamically changed to wire-based distribution structure is described, other imple- 
different databases by simply reconfiguring the database mentations include satellite communications (e.g., DSS 
management API, without affecting the other parts of the technologies), RF communication, or other wireless tech- 
event logging system. 45 nologies. Moreover, the network can be constructed using a 

A method for logging events in an interactive entertain- combination of wireless and wire-based technologies, 

ment network system is also described. The user interface unit 26 is capable of requesting a 

plurality of services from the headend 22. The headend 

BRIEF DESCRIPTION OF THE DRAWINGS supplies these services on an individual basis to the request- 

FIG. 1 is a block diagram of an event logging system for 50 m g user interface unit. Example services include programs, 

an interactive entertainment network system. video -on-demand (VOD), an electronic programming guide 

HG. 2 is a flow diagram illustrating general steps in a (EPG), shopping services, banking services, and the like. In 

method for logging events in an interactive entertainment ? ne ^bodament the servic* apphcalions are made available 

network svstem headend on different channels so that tuning to a 

' . 5s channel effectively requests the service on-demand. There 

FIG. 3 is a software-based architectural diagram of the may be a des i gnate d channel for VOD, a designated channel 

event logging system according to one implementation. for EPG> onc or more channcls for snoppmgj and one or 

FIGS. 4 and 5 present a flow diagram of a method for more channcls for banking. When the viewer tunes to the 

logging events according to the implementation of FIG. 3. EPG channel, for example, the headend 22 of the interactive 

FIG. 6 is a block diagram of an event configuration 60 entertainment network system 20 downloads the EPG appli- 

manager used to configure the event logging system. cation and information over the distribution network 28 to 

the requesting user interface unit 26. The electronic pro- 

DETAILED DESCRIPTION OF THE gramming guide allows a user to scroll through a grid-like 

PREFERRED EMBODIMENT men u which correlates program listings and specified start 

FIG. 1 shows an interactive entertainment network system 65 times. 

20 that is implemented with an event logging system. In the The user interface unit 26 includes an I/O port 30 to 

illustrated implementation, the interactive entertainment receive video and digital data from the headend 22 and to 
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transmit digital data back to the headend. The user interface Examples of system events include excessive network 

unit also includes a processor 32, an event buffer 34, and a errors, failure in a system service, or failure to start a logon 

non-volatile memory 36. The I/O port 30, processor 32, application. "Security events" concern the security of the 

buffer 34, and memory 36 are intercoupled by a multi-bit bus interactive entertainment network system. Examples of 

38. It is noted that the buffer 34 might be configured as part 5 security events include use of an incorrect password by a 

of the memory 36, but is shown separately to assist in user logging into the user interface unit, or authentication 

describing an aspect of this invention that is discussed more failures when attempting to authenticate a merchant during 

fully below. a commerce transaction over the distribution network. 

An event logging system, which is referenced generally "Application events" concern operation of applications run- 
by numeral 50, has components distributed throughout the 3° ning on the user interface units. An example of an applica- 
interactive entertainment network system 20. Some of the lion event might be button presses on a remote control 
components reside at the headend 22, other components handset while the viewer is in an active application, 
reside at the user interface unit, and still other components Events are also categorized into three general types: 
reside at locations other than the headend and user interface informational, warning, and error. "Informational events" 
unit. Events are detected at the user interface unit 26 and 15 are used for statistical reporting and for debugging purposes 
reported to the headend 22. as well as to report the general status of the user interface 

FIG. 2 shows the general steps for operating the event umt - "Warning events" are used to report problems that are 

logging system 50. At step 100, the user interface unit 26 not immediately troublesome, but which might indicate a 

determines whether an event is a loggable event. As noted more dangerous problem in the future. For example, an 

above, the headend 22 is expected to support hundreds of 20 application reports a warning event when it is running out of 

thousands of homes. If all events generated by each user resources. "Error events" are used to report a problem that 

interface unit were logged at the headend, there would be a results in a loss of functionality or data. Examples of error 

vast quantity of data sent to the headend and potential eveilts include an application failing to load or a system 

overloading of the interactive entertainment network sys- service failing to start. Error events occur infrequently, 

tem. Accordingly, the user interface unit 26 separates log- 25 In addition to the classes and types just described, each 

gable events from non-loggable events to avoid overburden- event can be assigned a degree of importance or importance 

ing the system. The user interface unit can be configured to level. The importance level is a binary value (e.g., 16-bit) 

choose different groupings of events for logging. that is attached as the upper bits to the binary value rep re - 

Loggable events are reported to the headend 22 over the sen ting the specific event. The importance level is used to 

distribution network 28 (step 102). The event logging sys- 30 partition events in such as way that a system administrator 

tem is designed so that the user interface unit 26 does not can selectively determine the level of events that are 

need to know the exact location to report the events at the reported to the headend from a particular event source, 

headend. The headend selects an appropriate database to The events are detected at the user interface unit in 

store event information pertaining to the reported events 35 various ways. For instance, the processor 32 can electroni- 

(step 104). An appropriate database is selected based upon cally track when the viewer depresses control keys on a 

the kind of events being logged. The event logging system remote control handset to detect application events, or when 

is also designed to permit the operator to configure where the a user enters a wrong password to detect security events, 

events are actually logged to promote flexibility in resource Interrupts are one common way to make the processor 32 

allocation. At step 106, the event information is logged in the 4Q aware of events, although there are other known techniques 

selected database, which might be located at the headend or for alerting the processor to possible events. Once detected, 

another remote location. the event evaluator 52, which is a program operating on the 

With reference again to FIG. 1, the event logging system processor 32 in the illustrated implementation, decides 
50 has an event evaluator 52 that resides at the user interface whether to event is loggable or not. 
unit to perform an initial event screening. The event evalu- 45 For purposes of continuing discussion, suppose a system 
ator 52 determines whether an event occurring at the user administrator of the interactive entertainment network sys- 
interface unit is a loggable event or a non-loggable event. tem wants to monitor events that reflect viewers' usage of 
Routine operation at the user interface unit gives rise to the electronic programming guide. For instance, the admin- 
many possible events, but not all of the events will be istrator might wish to monitor what programs the viewer 
recorded or logged. 50 considers when scrolling through the EPG by monitoring 

To assist in making a determination, an event filter criteria channel up/down inputs from a remote control handset or 
54 is stored in memory 36 at the user interface unit 26 to set-top box control panel. An EPG application 60 is shown 
specify which events are to be logged. The event filter stored in memory 36. The EPG application 60 is down- 
criteria 54 can be configured by the headend to enable or loaded from the headend via distribution network 28 to I/O 
disable specific subsets of events so that only enabled events 55 P orl 30 of user interface unit 26. As noted above, the EPG 
arc reported. Disabled subsets of events arc considered to be application can be launched by tuning to a channel desig- 
non-loggable events and are not recorded. In one implemen- nated to display the EPG. The EPG application 60 executes 
tation (described more fully below), the event filter criteria on the processor 32. 

contains sets of bit flags that are set if the corresponding The administrator configures the event filter criteria 54 at 

event kind is to be logged. Configuring the event filter 60 the user interface unit 26 to enable the class or application 

criteria 54 is discussed below in more detail with reference events and the type of information events. If further distinc- 

to FIG. 6. It is further noted that the headend can enable or tion is permitted, the event filter criteria might also be 

disable the event evaluator 52 entirely to thereby turn off all configured to recognize events as arising from use of the 

event logging for that user interface unit. EPG. 

Events are categorized into three primary classes: system 65 As the processor receives event-related interrupts, the 

events, security events, and application specific events. executing event evaluator 52 looks to the event filler criteria 

"System events" concern operation of the operating system. 54 to determine whether an event occurring at the user 
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interface unit is a loggable event or a non-loggable event. In Upon receipt, the event log manager 56 determines where 

this example, channel up/down commands while the user is to log the event information. The event logging system 50 

active in the EPG application 60 represent loggable events, includes at least one database at the headend, represented by 

whereas channel selections while the user is operating i og database 62, to store the event information pertaining to 

outside of the EPG application might not be loggable events. 5 tne loggable events reported by the event evaluator 52. The 

The event evaluator 52 records the loggable event, but will event logging system 50 is likely to have multiple log 

not record the non-loggable event. As a result, the event databases, including a database dedicated to storing system 

evaluator 52 performs a task of filtering usable events for a e a daUbase dedicated lo storing securit events> and 

seected analysis from events that are riot relevant to the a database dedicaled t0 storing application events. In 

selected analysis. This filtering reduces the amount of infor- 1Q additi tfae eyent { m m 5Q mi M indude Qne Qr 

mation that is sent back to the headend and eventually mofe { located remold from ^ headend ag 

logged. In the illustrated embodiment event evaluator 52 re esented b a mird arty database 64 in FIG L ^ 

comprises a pro-am stored in memory 36 and executed on e le of a third dalabase ^ a s unit , ocated at 

processor 32. The program-based event evaluator is a mcrchanl - 5 facilities to lo events relati t0 viewers 

descnbed below in more detail with reference to FIG. 3. 1$ shopping ^ wfaen brQWsing ^ merchant>s catalog 

The event logging system 50 also has an event log over me netW ork. 

manager 56 resident at the headend 22 to manager where ^ , , cjC . , . „ a U1 t 

* * u i a t^u * i « m * .u The event log manager 56 is dynamically configurable to 

events are to be logged. The event evaluator 52 at the user lA c ? , 6 j * u * i • \ 

. , c ■* # .u i i.i * . i j ■ * * select one of the storage databases for logging the event 

interface unit 26 reports the loggable events over the distn- . p ~ # ? « * ifi i 

, t . , niL , information. The event log manager 56 preferably employs 

bution network 28 to the event log manager 56. The event ™ , . ... 4 . & , / J , . J e 

t - c . r U1 4 , ~ 4 2U an relational list or table 66 that correlates different kinds of 

log manager 56 LSpreterably a program that executes on one . „ . .. ^ 

r , U «u ; i «u * ^ event information with corresponding databases. For 

or more of the servers that make up the server system 24. . , 

r™ . , - r i_ j ■ ii uistance, the relational list might correlate system events 

The event log manager 56 can be dynamically moved about . , ' . . , . A f . . , 3 . 

tl _ * *i_ u j j u * with one database resident at the headend, security events 

the servers at the headend as resources change, without it _ , t , . , A 4 iU , , , / 

«... ^ . f , . , , . . with another database resident at the headend, and apphca- 

aftec ing operate of theevent logging system. 25 ^ events ^ ^ olher |n fac ^ ^ q£ 

Aforwarding registry 58 is utilized by ^the event evaluator application events migh , be mrther divided int0 (1) events 

52 to locate the event log manager 56 at the headend, thereby ^ jn , 0 lications mn b tne entertainment network 
alleviating the need for the event evaluator to know where such ^ ^ and VQD which are , 0 be 

the log manager 56 is physically and actually residing at the l d Qn Qne Qr mofe da(abases a , (he headend and (2) 

headend. The fowarding registry 58 is shown in the com- 3 o events that pertain to applications designed for third parties, 
munication path from the user interface unit to the headend. such as a merchan ,. s catal on the home sh ^ channel 
It can be is located at the headend, or haye components which are tQ ^ { d a , ^ lhM da , abase fi4 remote 
distributed over the entertainment network system. For ^ Qm mg be adend 

event logging, the event evaluator 52 sends event-related _ , ,. , 

messages over the distribution network 28 which contain a 3S The rel atl onal list 66 is shown embodied as a source string 
general well-known address for the event log manager. The store t 68 - ^ ™ges used to report events from the user 
well-known address is translated by the forwarding registry interface unit 26 contain a source string of identifiers as to 
into the true address. If the event log manager 56 is moved, tbe s P ec, fi c event ' sourc / of «heevent, class and type of 
the forwarding registry is simply updated or reconfigured to ev f nl ' and ™I»rt«we of event. The message also includes 
account for the change of location. One implementation of « " ' descn P llon of the event - Tta source string store 68 relates 
a forwarding registry is through use of distributed compul- messa g, e source slrln | , wi,h a Particular storage location, 

ing techniques based on features of a network component ^ event lo S mana S er 56 ««npu» the source string from 
object model (network COM) which includes directory l he event sporting messages received from the user inter- 
services and remote procedure calls (RPCs). This imple- face umt to me stlin & kept in the source string store 
mentation is described below with reference to FIG. 3. 45 68 t0 discern wnich database should s,ore the cvent infor - 

The forwarding registry 58 can be configured to alterna- 
tively forward the event information to a location other than ^ relational list 66 affords additional design flexibility 
the event log manager. For example, the system operator in that database resources can be altered (added, reduced, 
might wish to run diagnostics on the interactive entertain- moved, etc.), or in that the event information can be rerouted 
ment network system, and use the event information as a 50 t0 differeDt ones of the databases, without affecting opera- 
form of feedback. In this case, the system operator config- tlon of the event lo g8 ir ig system. Once an alteration or 
ures the forwarding registry to route event information to a rerouting is made, the relational list 66 is updated or 
diagnostic system, rather than the event log manager. reconfigured to reflect the new storage plan. The event 

When reporting the events, the event evaluator 52 sends mana e er 56 » not impacted by the change, but 

event information containing data about the events 55 ra [ her uses the f reconfigured relational hst to determine 
themselves, as well as other information concerning source where event formation is to be logged, 
of the event, type and class of event, and other descriptive Event logging system 50 is also illustrated as having a 
data. The event evaluator can be configured to report the database locator 70 which performs the task of actually 
loggable events in real-time as they arise. However, cstab- locating and sending the event information to the selected 
lishing communication links with the headend often requires 60 database. Preferably, the database locator 70 is an applica- 
an expenditure in system resources, and thus, it might be lion program interface executing on the server system 24. 
more feasible to report groups of events. In this case, the The database locator 70 and databases 62 and 64 are 
loggable events are batched in event buffer 34 and then implemented using ODBC (Open DataBase Connectivity) 
periodically reported in batch to the event log manager 56 at protocols. 

the headend. The local event buffer can be programmed or 65 FIG. 3 shows a program-based architectural layout of the 
controlled to report the events at specified times or when a event logging system 50 according to one implementation, 
selected number of events has been recorded therein. The event logging system is implemented using object- 
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oriented applications. In the multi -processing entertainment 
network system, it is desirable to provide facilities for 
allowing one process to utilize the resources of another 
process. It is also desirable to provide a standard interface 
mechanism between processes so that application programs 5 
from different vendors can conveniently share resources 
using a common protocol. The object-oriented mechanism 
utilizes the concept of "objects" and "object interfaces" to 
specify interactions between computing units, such as the 
user interface units and the headend servers. An object in 10 
this environment is a unit of functionality that implements 
one or more interfaces to expose that functionality to outside 
applications. An interface is a contract between the user, or 
client, of some object and the object itself. In more practical 
terms, an object is a collection of related data and functions 15 
grouped together for a distinguishable common purpose. 
The purpose is generally to provide services to client pro- 
cesses. An interface is a grouping of semantically related 
functions through which a client process can access the 

services of the object. 20 Parameter 

The event logging system 50 shown in FIG. 2 is archi- 
tected using a protocol known as the "network component 
object model", or network COM. Network COM is an 
extension of COM, a customarily used protocol for design- 
ing operating systems and applications. COM specifies how 25 
objects interact with each other using interfaces. Object 
linking and embedding (OLE) from Microsoft Corporation 
is an example COM-based language that is commercially 
available. OLE and COM have been well documented and 
will not be explained in detail. For more information regard- 
ing OLE and COM, refer to OLE 2 Programmer's Reference 
and Inside OLE 2, both published by Microsoft Press of 
Redmond, Wash., and both of which are hereby incorporated 
by reference. 

In the COM environment, an interface is a block of 
memory containing an array of function pointers — that is, a 
function table. Through a standard object interface referred 
to as IUnknown, a client process can obtain a pointer to any 
interface supported by an object. When such an interface 
pointer has been obtained, it is said that the client process 
has obtained an interface on the object, allowing the client 
process to bind to the object. The pointer does not provide 
access to the entire object; instead, it allows access to one 
interface on that object. 

Network COM is an extension of COM in that it specifies 
how objects interact with each other over a network. Here, Function 
objects are distributed at the headend and user interface unit 
and interact over the interactive distribution network. To a 
client process, the object appears to be readily available, as 5Q 
if it were running on the same computer. In reality, however, 
the object might be is running on a computer that is remotely 
located and only accessible over the network. 

Calling a remote interface (one that is in a different 
address space than the calling process) requires the use of 55 
remote procedure calls (RPCs), which involve "stubs" and 
"proxies," and topics such as "marshalling" and "unmar- 
shalling" of procedure parameters. These mechanisms arc 
well understood and are documented in the books mentioned 
above. In regard to these topics, also refer to "X/Open DCE: 60 
Remote Procedure Call," published by X/Open Company 
Ltd., U.K, which is also incorporated by reference. 

The COM-based implementation of the event logging 
system 50 and its operation will now be described with 
reference to the architectural diagram of FIG. 3 and the flow 65 
diagrams of FIGS. 4 and 5. Events are initially captured at 
the processor of the user interface unit (step 200 in FIG. 4). 



The event evaluator of the event logging system 50 is 
implemented as a log application program interface (log 
API) 80 which runs on the processor at the user interface 
unit. The log API 80 determines whether an event is a 
loggablc event, which should be recorded, or a non-loggable 
event which should not be recorded (step 202). The log API 
80 looks to the event filter criteria 54 stored in the memory 
at the user interface unit as guidance to which events are to 
be logged. The kinds of events which are logged at the 
headend can be dynamically changed by reconfiguring the 
event filter criteria 54, as represented by step 204. If the 
event is not loggable (i.e., the "no" branch from step 206), 
the processor does not record the event (step 208 in FIG. 4). 

Table 1 explains various parameters that make up the log 
API 80. 

TABLE 1 



Parameters for Log API 



Description 



30 



35 



lpszSource 
fwiype 

fdwInfoLevei 



fwCategory 
dwID 

IpszMessage 
cStrings 

plpszStrings 

cbData 

lpbData 



Identifies the source of event. 

Specifies the specific class and type of the event being 
logged. 

Specifies the approximate importance of the event, as 
well as a general source specific value that is used to 
selectively enable or disable reporting of groups of 
events. 

Specifies the category to which this event belongs, and is 
source specific. 

Source specific event identifier. 

Specifies a null- terminated string that describes the event. 

Specifies the number of substitution strings pointed 

to by the plpszStrings parameter. 

Points to an array of null-terminated strings that should 

be inserted into the message associated with this event 

Specifies the number of bytes of event specific raw 

binary data associated with the event. 

Points to a buffer containing the event specific raw 

binary data. 



Table 2 shows an example set of API function calls for the 
log API 80. Table 1 lists the parameters from table 1 and a 
brief description. There is no return value for the following 
functions. 



TABLE 2 



45 



Log API Function Calls 



Parameters 



Description 



CHentReportEvent lpszSource, fwType, 

fdwlnfo Level, 
fwCategory, dwID, 
cStrings, 
plpszStrings, 
cbData, lpbData 
ClientReportEventSubst lpszSource, fwType, 
fdwlnfo Level, 
fwCategory, dwID, 
cStrings, 
plpszStrings 
ClientReportSimpleEvent lpszSource, fwType, 
fdwlnfo Level, 
fwCategory, dwID 
lpszSource, 
fdwlnfo Level, 
IpszMessage 



ClientReportDebugEvent 



Flexible Logging Func- 
tion and is intended for 
use when arbitrary binary 
data is included with the 
event. 

Allows for substitution of 
strings into the event text 
at run time, but does not 
allow arbitrary binary 
data. 

Compact function for 
reporting events without 
data. 

Allows caller to specify 
static, non- localized 
string that should be 
placed in event log. It is 
used only for reporting 
debugging information. 



If an event is determined to be a loggable event (i.e., the 
"yes" branch from step 206), the log API 80 reports the 
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loggable event to headend 22 on a per-event basis or in 
batch. The event log manager at the headend is implemented 
as a logging service object 82 with interface 84 which 
executes on the server system. When the log API 80 wishes 
to report a loggable event or a batch of loggable events, the 5 
log API calls the logging service object 82 using remote 
procedure calls (RPCS) over the distribution network (step 
210 in FIG. 4). The RPCs contain a global address that is 
used to locate the interface for the logging service object no 
matter where the logging service object is physically resid- 10 
ing at the headend at that time. 

There are many objects operating on the server system at 
the headend. The objects collectively form a distributed 
object store because they are kept on multiple different 
servers. To locate the logging service object at the headend, 35 
regardless of where it physically resides, this implementa- 
tion of the entertainment network system employs a direc- 
tory services application 86 that remains running on the 
headend servers and user interface units. The directory 
services application 86 allows applications executing on the 20 
user interface units or headend to look up and activate 
objects in the object store without knowing where the object 
is physically stored. In fact, the object might very well be 
stored in more than one place, or moved from place to place. 

The directory services devises a hierarchical name space 
using directories. Every object listed in the directory ser- 
vices has a unique name made up of the object's own name 
and a unique name of the directory that contains the object. 
A set of such names is referred to as the name space. In the 
distributed object store maintained for the interactive enter- 
tainment network system, there is only one root so that all 
objects belong to a single global distributed name space. 
Subsets of the global name space reside on individual 
machines, and are termed local name spaces. 

The log API 80 uses a remote procedure call to activate 
the logging service object. The RPC contains the unique 
name of the logging services object 82 which the directory 
services 86 uses to actually locate the logging service object 
(step 212 in FIG. 4). Once located, the log API 80 binds to 
the logging service object 82 to report the loggable events 
detected at the user interface unit (step 214). By using a 
COM-based architecture, the logging service object can be 
moved to different servers at the headend as planning or 
organizational needs change, without affecting the event 
logging operation. If moved, a new directory name is 
assigned to the logging service object and the directory 
services 86 is modified to reflect the new location of the 
logging service object (step 216 in FIG. 4). This promotes 
tremendous flexibility. 

The logging service object 82 selects an appropriate 
database to store the event information for the loggable 
events reported by the user interface unit. The logging 
service object 82 examines the source string on the message 
from the log API in view of the strings kept in service string 55 
store 68 to select the appropriate database for logging the 
event information (step 218 in FIG. 5). 

The event logging system supports many different data- 
bases 88(1)--88(N) for storing event information pertaining 
to different kinds of loggable events. Some of the databases 
are locally resident at the headend while other databases are 
located remotely from the headend. The databases 88(l)-88 
(N) are preferably SQL (structured query language) servers 
which are ODBC compliant. Once the logging service object 
82 selects the appropriate database 88(1)-88(N) (step 220 in 65 
FIG. 5), the logging service object 82 invokes an ODBC API 
90 or a separate user interface provided with OBDC to locate 



25 



30 



35 



40 



the appropriate storage location (step 222). The event infor- 
mation is then routed to the storage location for logging (step 
224). The locations for storing event information can be 
dynamically changed to different databases by either (1) 
reassociating the source strings with different storage 
locations, or (2) reconfiguring the ODBC layer to route the 
event information to different locations, without affecting 
the other parts of the event logging system. This is repre- 
sented by independent configuration step 226. 

FIG. 6 shows an event configuration subsystem 92 
according to another aspect of the event logging system. 
Event configuration subsystem 92 has an event configura- 
tion manager 94 which is capable configuring the event filter 
criteria in the user interface units. Preferably, the event 
configuration manager 94 resides at the headend and down- 
loads the criteria over the distribution network to the user 
interface unit using a network protocol. The illustrated 
embodiment employs a standard network/database manage- 
ment protocol, such as the well known SNMP (Simple 
Network Management Protocol), to accomplish this con- 
figuration task. An SNMP application 96 is shown stored in 
memory 36 and is executable on processor 32 at the user 
interface unit. 

The event configuration manager 94 seizes control of a 
shared portion of memory 36 through the SNMP application 
96 and writes the new event filter criteria to the memory. 
Once configured, the event evaluator 52 of the user interface 
unit uses the event filter criteria set by the event configura- 
tion manager 94 to evaluate and screen events. The con- 
figuration and use of the filter are therefore separate and 
independent of the other, permitting dynamic alteration of 
the criteria without affecting or reconfiguring the event 
evaluator 52 itself. In this manner, the system administrator 
can set the filter criteria in a large number of user interface 
units in different subscriber homes from the headend. 

Table 3 lists variables that can be configured as part of the 
event filter criteria. 

TABLE 3 



45 



50 



Variable 



Event Filter Criteria Variables 



Description 



stbSystem- 
EventTypes 



stb Security- 
Eve ntTypes 



stbAppltcation- 
EventTypes 



60 



stbSystem- 

InfoLevel 

stbSecurity- 

InfoLevel 

stbApplication- 

InfoLevel 

stbMaxBufferAge 



This variable is a bit flag for the class of system 

events and consists of the OR'ed value of the three 

event types as follows. If a bit is set, that type of 

system class event will be reported. 

EVENTLOG_ERROR_TYPE 

EVENTLOG_WARNING_TYPE 

E VENThOG_INFO R M ATI ON_TYP E 

This variable is a bit flag for the class of security 

events and consists of the OR'ed value of the three 

event types as follows. If a bit is set, that type of 

system class event will be reported. 

E VENTLOG_ERROR_TYP E 

EVENTLOG_WARNING_TYPE 

E VENTLOG_IN FORM ATTON__TYPE 

This variable is a bit flag for the class of application 

events and consists of the OR'ed value of the tbree 

event types as follows. If a bit is set, that type of 

system class event will be reported. 

EVENTLOG_ERROR_TYPE 

EVENTLOG_WARNING_TYPE 

E VENTLOG_IN FORM ATION_TYPE 

Specifies the maximum infolevel of system class 

events that should be reported to the central log server. 

Specifies the maximum infolevel of security class 

events that should be reported to the central log server. 

Specifies the maximum infolevel of application class 

events that should be reported to the central log server. 

Specifies the number of seconds after which the local 
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Variable 



Event Filter Criteria Variables 



Description 



event buffer on the user interface unit should be 
forwarded to the central log server regardless of the 
number of events in the buffer. 
stbMaxBufferSize Specifies the maximum total bytes of event related 

data that should be buffered before forwarding the 10 
events to the central log server. If this value is 
exceeded, all events in the buffer are forwarded 
immediately, and the buffer age counter is reset to 0. 



It is noted that in the event filter criteria can be updated 15 
or modified in other ways. For example, the criteria can be 
loaded on a memory diskette which is physically ported to 
the user interface unit and downloaded locally using a 
memory drive. 

Aspects of this invention may also be implemented in 2 q 
network or distributed systems other than the described 
interactive television embodiment. For example, the event 
logging system might be implemented in an Internet-based 
context having a content or program provider which serves 
content to and interacts with multiple user computing units. 
Additionally, aspects of the event logging system can be 25 
used in local or wide area networks, such as those used by 
companies, which have servers serving multiple clients. 

In compliance with the statute, the invention has been 
described in language more or less specific as to structure 
and method features. It is to be understood, however, that the 30 
invention is not limited to the specific features described, 
since the means herein disclosed comprise exemplary forms 
of putting the invention into effect. The invention is, 
therefore, claimed in any of its forms or modifications within 
the proper scope of the appended claims appropriately 35 
interpreted in accordance with the doctrine of equivalents 
and other applicable judicial doctrines. 

I claim: 

1. An event logging system for use in a network system 
having a content provider interconnected via a distribution 40 
network to at least one user interface unit, individual events 
being detected at the user interface unit, the event logging 
system comprising: 

an event evaluator resident at the user interface unit to 
determine whether an event occurring at the user inter- 45 
face unit is a loggable event or a non-loggable event; 
and 

an event log manager resident at the content provider to 
manage where events are to be logged, the event 
evaluator reporting the loggable event via the distribu- 50 
tion network to the event log manager at the content 
provider. 

2. An event logging system as recited in claim 1, wherein 
the event evaluator does not record the non-loggable events. 

3. An event logging system as recited in claim 1, wherein 55 
the event evaluator is configured to be selectively enabled or 
disabled. 

4. An event logging system as recited in claim 1, wherein 
the event evaluator reports a degree of importance of the 
loggable event. 60 

5. An event logging system as recited in claim 1, wherein 
the event is categorized into one of three classes selected 
from a group comprising: (1) system events for reporting on 
the interactive entertainment network system, (2) security 
events that relate to security aspects of the interactive 65 
entertainment network system, and (3) application events 
that pertain to operation of the user interface unit. 



6. An event logging system as recited in claim 1, further 
comprising: 

a buffer to temporarily batch multiple loggable events; 
and 

the event evaluator being configured to periodically report 
the batched loggable events to the event log manager. 

7. An event logging system as recited in claim 1, further 
comprising: 

multiple servers at the content provider; and 
the event log manager is configured to operate on a set of 
one or more of the servers and can be dynamically 
reconfigured to operate on a different set of one or more 
servers. 

8. An event logging system as recited in claim 1, further 
comprising a database at the content provider to store 
information pertaining to the event reported by the event 
evaluator. 

9. An event logging system as recited in claim 1, further 
comprising: 

multiple databases for storing different kinds of event 
information; 

a relational list at the content provider to relate the kinds 
of event information with the appropriate databases; 
and 

the event log manager using the relational list to select the 
appropriate database for storing information pertaining 
to the event reported by the event evaluator at the user 
interface unit. 

10. An event logging system as recited in claim 9, wherein 
at least one of the multiple databases is resident at the 
content provider and at least one of the multiple databases is 
situated remotely from the content provider. 

11. An event logging system as recited in claim 1, further 
comprising: 

a processor resident at the user interface unit; and 
the event evaluator comprising a log application program 
interface (log API) which executes on the processor. 

12. An event logging system as recited in claim 1 1, 
further comprising: 

a server resident at the content provider; and 
the event log manager comprising a callable logging 
service object that can be called by the log API using 
a remote procedure call (RPC) over the distribution 
network. 

13. An event logging system for use in a network system 
having a content provider interconnected via a distribution 
network to at least one user interface unit, individual events 
being detected at the user interface unit, the event logging 
system comprising: 

an event log manager resident at the content provider to 

manage where events are to be logged; 
the user interface unit being configured to report events to 

the event log manager over the distribution network; 

and 

a forwarding registry that is utilized by the user interface 
unit to locate the event log manager at the content 
provider, the forwarding register being configurable to 
change where events are reported at the content pro- 
vider. 

14. An event logging system as recited in claim 13, 
wherein the forwarding registry is configured so that the 
events are reported to a location other than the event log 
manager. 

15. An event logging system as recited in claim 13, further 
comprising: 
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multiple servers at the content provider, the event log 
manager being supported by one or more of the servers; 
and 

the forwarding register being utilized by the user interface 
unit to report the events to the event log manager 5 
regardless of where the event log manager is physically 
located on the one or more servers. 

16. An event logging system as recited in claim 13, further 
comprising an event evaluator resident at the user interface 
unit to determine whether an event occurring at the user 10 
interface unit is a loggable event to be sent to the event log 
manager. 

17. An event logging system as recited in claim 13, further 
comprising: 

multiple databases for storing different kinds of event 15 
information; 

a relational list at the content provider to relate the kinds 
of event information with the appropriate databases; 

aQd 20 
the event log manager using the relational list to select the 
appropriate database for storing information pertaining 
to the event reported by the event evaluator at the user 
interface unit. 

18. An event logging system as recited in claim 17, 2 5 
wherein at least one of the multiple databases is resident at 
the content provider and at least one of the multiple data- 
bases is situated remotely from the content provider. 

19. An event logging system for use in a network system 
having a content provider interconnected via a distribution 30 
network to at least one user interface unit, individual events 
being detected at the user interface unit, the event logging 
system comprising: 

an event log manager resident at the content provider to 
manage where events are to be logged; 35 

the user interface unit being configured to report events to 
the event log manager over the distribution network; 

multiple storage locations to record event information 
pertaining to the events reported to the content provider 
from the user interface unit; and 40 

the event log manager being configurable to select a 
storage location from among the multiple storage loca- 
tions. 

20. An event logging system as recited in claim 19, further 
comprising: 

a relational list that relates different kinds of event infor- 
mation with corresponding storage locations; and 
. the event log manager using the relational list to select the 
appropriate database for storing the event information. 50 

21. An event logging system as recited in claim 19, 
wherein at least one of the multiple databases is resident at 
the content provider and at least one of the multiple data- 
bases is situated remotely from the content provider. 

22. An event logging system as recited in claim 19, further 55 
comprising an event evaluator resident at the user interface 
unit to determine whether an event occurring at the user 
interface unit is a loggable event to be sent to the event log 
manager. 

23. An event logging system for use in a network system, 60 
the event logging system comprising: 

a memory resident at a computing unit; 

an event configuration manager capable of writing an 
event filter criteria to the memory resident at the 
computing unit, the event filter criteria being used to 65 
determine whether an event is a loggable event or a 
non-loggable event; and 



45 



an event evaluator resident at the computing unit and 
operably coupled to access the memory, the event 
evaluator being configured to determine whether an 
event should be logged in accordance with the event 
filter criteria stored in the memory. 

24. An event logging system as recited in claim 23, 
wherein the event configuration manager is located remotely 
from the computing unit and writes the event filter criteria to 
the memory over the distribution network. 

25. An event logging system as recited in claim 23, 
wherein: 

the event configuration manager writes a new event filter 
criteria to the memory independently of the event 
evaluator; and 

the event evaluator evaluates subsequent events using the 
new event filter criteria stored the memory. 

26. An event logging system for use in a network system 
having a content provider interconnected via a distribution 
network to at least one user interface unit, individual events 
being detected at the user interface unit, the event logging 
system comprising: 

a processor resident at the user interface unit; 

a log application program interface (log API) executing 
on the processor to determine whether an event is a 
loggable event; 

a server resident at the content provider; 

a logging service executing on the server, the logging 
service being configured as an callable object with a 
defined interface, the logging service object being 
callable by the log API using a remote procedure call 
(RPC) over the distribution network; 

the log API being configured to call and bind to the 
logging service object and to report loggable events to 
the logging service object; 

multiple databases to store event information pertaining to 
different kinds of loggable events; 

the logging service object being further configured to 
select an appropriate database from among the multiple 
databases to store event information for a loggable 
event reported by the user interface unit; and 

a database management application program interface 
executing on the server to route the event information 
from the logging service object to the appropriate 
database selected by the logging service object. 

27. An event logging system as recited in claim 26, further 
comprising: 

a memory resident at the user interface unit to store an 
event filter criteria, the log API using the event filter 
criteria to determine whether an event is a loggable 
event. 

28. An event logging system as recited in claim 27, further 
comprising: 

an event configuration manager separate from the user 
interface unit which accesses the memory at the user 
interface unit to write the event filter criteria into the 
memory. 

29. An event logging system as recited in claim 26, further 
comprising: 

multiple servers resident at the content provider, the 
logging service object being executable on one or more 
of the servers. 

30. An event logging system as recited in claim 26, further 
comprising: 

a source string store that identifies an appropriate database 
from among the multiple databases for a given kind of 
loggable event reported by the log API; and 
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the logging service object utilizing the source string store 41. A method as recited in claim 33, wherein the storing 

to select the appropriate database for storing event step comprises storing the event information pertaining to 

information pertaining to that loggable event. some loggable events at a storage location that is local to the 

31. An event logging system as recited in claim 26, content provider and the event information pertaining to 
wherein at least one of the multiple databases is resident at 5 otn cr loggable events at a storage location that is remote 
the content provider and at least one of the multiple data- & om the content provider. 

bases is situated remotely from the content provider. 42 A method for logging an event in a network system 

32. An event logging system as recited in claim 26, havmg first and second computing units interconnected via 
wherein log API is configured to perform a report function a network > the method comprising the following steps: 

to report a loggable event to the logging service object, the 10 capturing an event at a first computing unit; 

report function including parameters selected from a group establishing a forwarding registry to direct where the 

comprising: (1) identity of user interface unit; (2) class of event should be reported at the second computing unit; 

event; (3) importance level of event; and (4) data. reporting the event captured at the first computing unit to 

33. A method for logging an event in a system having a » , P lacc at the secoi ? d computing unit that is located by 
content provider interconnected via a distribution network to is the forwardin S registry; and 

at least one user interface unit, individual events being changing the forwarding registry to alter the place at the 

detected at the user interface unit, the method comprising the ,. Se A COnd ™™V uim & un }\ to which the event is reported, 

following stens* 43. A method as recited in claim 42, further comprising 

8 . . p " . the additional step of determining, at the first computing 

determining, at the user interface unit, whether the event unil> whe ther the event is a loggable event. 

is a loggable event; 20 44 a method for logging an event in a network system 

reporting loggable events to the content provider; having first and second computing units interconnected via 

selecting a storage location to store event information a network, the method comprising the following steps: 

pertaining to the loggable events; and capturing an event at the first computing unit; 

storing the event information at the storage location. 25 sporting the event to the second computing unit; 

34. A method as recited in claim 33, further comprising selecting a storage location from a group of storage 
the following additional steps: locations to store event information pertaining to the 

. , , , event; and 

reporting the loggable events to an event log manager ch ^ ^ Qf e tQ cfa wfaere 

provided at one location within the content provider; the event information ^ stored 

moving the event log manager from the one location to a 30 45. A method as recited in claim 44, further comprising 

new location within the content provider; and the additional step of determining, at the first computing 

subsequently reporting the loggable events to the event umt > whether the event is a loggable event. 

log manager at the new location. 46 A method as recited in claim 44, further comprising 

35. A method as recited in claim 33, further comprising the following additional steps: 

the following additional steps: 35 correlating different kinds of event information with asso- 

, . • ■ * _r 1 ciated ones of the storage locations; and 

storing an event filter criteria at the user interface unit; and , . . , , , . . 

t t . . selecting a suitable storage location in accordance with a 

the determining step comprises the step of examining the ^ of event information to be stored, 

event in accordance with the event filter criteria to 47. A method as recited in claim 44, wherein the group of 

decide whether the event is a loggable event. 40 storage locations contains storage locations local to the 

36. A method as recited in claim 33, further comprising second computing unit and storage locations remote from 
the step of reporting identification information pertaining to the second computing unit. 

the user interface unit. 48. A method for initializing an event logging system used 

37. A method as recited in claim 33, further comprising in a system having a server unit interconnected via a network 
the following additional steps: 45 to at least one client unit, the method comprising the 

batching multiple loggable events at the user interface following steps: 

unit; and ( a ) storing an event filter criteria in a memory resident at 

periodically reporting the loggable events that are the client unit, 

batched 0 5 ) determining, at the client unit, whether the event is a 

38. A method as recited in claim 33, wherein: 50 loggable event based upon the event filter criteria 
, , , , , , stored in the memory; and 

the loggable events are reported to an event log manager , * , . iL i jC1i .... 

tU ~. • , , , 11 ui 1 * * <* t ?i_ (c) changing the event niter criteria in the memory to a 

that is implemented as a callable object executing at the w • 1 , 

content provider; and new event filter catena so that subsequent events are 

analyzed under step (b) using the new event filter 

the reporting step comprises the step of calling the object 5S criteria 

using a remote procedure call over the distribution 49. A method as recited in claim 48, wherein the changing 

" e . tw ' . . . step (c) comprises remotely changing the event filter criteria 

39. A method as recited in claim 33, further comprising from a remote location by transmitting the new event filter 
the following additional steps: critefia over lhe distribulion network. 

correlating different kinds of event information with asso- 60 50. An event logging system for use in a network system 

ciated storage locations; and having a server interconnected via a network to at least one 

selecting a suitable storage location in accordance with a client, individual events being detected at the client, the 

kind of event information to be stored. event logging system comprising: 

40. A method as recited in claim 39, further comprising an event evaluator resident at the client to determine 
the additional step of reassociating the different kinds of 65 whether an event occurring al the client is a loggable 
event information with different storage locations to alter event or a non-loggable event based upon an event filter 
where the event information is stored. criteria; and 
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the event evaluator being reconfigurable to change the 
event filter criteria. 

51. An event logging system as recited in claim 50, further 
comprising a forwarding registry that is utilized by the client 
to locate a place on the server to report the loggable events, 
the forwarding register being configurable to change where 
events are reported at the server. 

52. An event logging system as recited in claim 51, further 
comprising: 

multiple storage locations at the server to record the 

loggable events; and 
an event log manager, resident at the server, which is 

configurable to select a storage location from among 

the multiple storage locations. 

53. A method for logging an event in a system having a 
server interconnected via a network to at least one client, 
individual events being detected at the client, the method 
comprising the following steps: 

determining, at the client, whether the event is a loggable 
event based upon an event filter criteria; and 

reconfiguring the event filter criteria to change which 
events are consider loggable events. 

54. A method as recited in claim 53, further comprising 
the following steps: 

reporting loggable events to a location at the server that is 

identified by a forwarding registry; and 
changing the forwarding registry to report the loggable 

events to another location at the server. 

55. A method as recited in claim 54, further comprising 
the following steps: 

selecting a storage location from among multiple storage 
locations at the server to record the loggable events; 
and 



i7,190 

20 

changing from one storage location to another to store the 
loggable events. 

56. A computer-readable medium used in an event logging 
system having a server interconnected via a network to at 

5 least one client, the computer-readable medium storing 
computer-executable instructions for performing the follow- 
ing steps: 

storing an event filter criteria at the client; 

10 determining, at the client, whether an event is a loggable 
event based upon the event filter criteria; and 

changing the event filter criteria to a new event filter 
criteria so that subsequent events are analyzed using the 
is new event filter criteria. 

57. A computer-readable medium as recited in claim 56, 
further comprising computer-executable instructions for per- 
forming the following steps: 

20 reporting loggable events to a location at the server that is 
identified by a forwarding registry; and 
changing the forwarding registry to report the loggable 
events to another location at the server. 

58. A computer-readable medium as recited in claim 57, 
25 further comprising computer-executable instructions for per- 
forming the following steps: 

selecting a storage location from among multiple storage 
locations at the server to record the loggable events; 
30 and 

changing from one storage location to another to store the 
loggable events. 

* * * * * 
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